Results 1 to 14 of 14
  1. #1
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default My first impression

    So without having any real need at this point, but with the focus on:

    1. Learning to deploy a standard for myself in doing unit tests (using JUnit) and developing a bit of a best practice for that, in order to save time
    2. Finding a way currently to do three simple tasks (clean, build/compile, test) in a way that devoids the need to write my own shell scripts
    3. Learning how the rest of the world does it.


    I decided to give a chance to either Ant or Maven.

    For example, this Finite State Machine implementation: Squirrel Foundation specifies a Maven dependency config in order to easily include and even download its package for inclusion in your project.

    Now without Maven I would need to download that package, put the jar in my classpath, and be up and running.

    I read the following guide:

    Java Build Tools: Ant vs Maven vs Gradle | Technology


    Then I ended up at Maven in Five Minutes

    I created the default "test" structure/environment/project and it compiles and runs.

    I notice that:

    1. The directory structure cannot be chosen (as it could with Ant?) and it has to be src/ with src/main/java/package-name, and src/test/java/package-name. In addition, class files end up in /target/classes. If you build a .jar file, it ends up in /target.

    2. You do not specify a target source file to compile. Will it compile every source it finds? I am used to just compiling the main source/java file I want to execute (the one that contains public static void main) and it will automatically compile all dependencies.

    This gives the benefit of easy compiling when some (unneeded) source files may be corrupt (non-compilable/uncompilable). Does Maven just compile every file it finds???? Is it possible to specify a certain "start" file?

    ===============================

    My goal with the unit tests is to provide test for all components once they work, so that when I change something, and it breaks, I will know where it has broken.

    Question:

    I currently have my project contained in two top-level packages, ie. one package is called "thunderbolt" (the name of my project) and the other is called "telnet" (the library supporting it). In due course probably they will be merged in some way (ie. thunderbolt.main and thunderbolt.telnet and preceded/prefixed with some personal identifier (net.xxx.thunderbolt). But currently these are two branches.

    1. Normally when I compile the main program file (thunderbolt/Server.java) it will just compile everything else in both branches.
    2. I understand in maven I may need to include both package trees. Ie. in the POM file it says:

    Java Code:
    <groupId>thunderbolt</groupId>
    <artifactId>thunderbolt</artifactId>
    The former refers to the package name, the latter to the root directory of the project. Is it possible to include a second groupId ?.

    So far I haven't tried it on my project yet, because it won't compile at this point.

    I wonder how easy it is to create additional targets. Ie. I sometimes will create a test program for testing a sub-feature, ie. a library feature. The test program is currently run using shell/batch scripts. I easily compile and run the entire suite using: "c" and "run", but any subfile can be compiled using "cc src\telnet\statemachine\MachineTest.java" (for instance). The benefit of a build environment would ordinarily be that I could create extra targets and run them easily, but I don't see this happening yet as the shell script seems much easier ?.

    Maven doesn't seem designed to create your own targets. Which means I need a new maven project but then I can't run it from the same directory ???.

    Do I need Ant for this?
    Last edited by Xen; 07-28-2015 at 11:56 AM.

  2. #2
    gimbal2 is offline Just a guy
    Join Date
    Jun 2013
    Location
    Netherlands
    Posts
    5,114
    Rep Power
    12

    Default Re: My first impression

    Typical questions one would ask when you brush over things with the minimal effort and don't take the time to dive in deeper.
    "Syntactic sugar causes cancer of the semicolon." -- Alan Perlis

  3. #3
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    13,541
    Rep Power
    26

    Default Re: My first impression

    Quote Originally Posted by Xen View Post
    2. You do not specify a target source file to compile. Will it compile every source it finds? I am used to just compiling the main source/java file I want to execute (the one that contains public static void main) and it will automatically compile all dependencies.

    This gives the benefit of easy compiling when some (unneeded) source files may be corrupt (non-compilable/uncompilable). Does Maven just compile every file it finds???? Is it possible to specify a certain "start" file?
    In a real project you do not have corrupt source files.
    Your entire project should build.
    Maven was written for real projects.

    As for your point 2, most Java is written for webapps, which do not have a main(). Indeed, they have multiple entry points (servlets or the equivalent depending on the framework used), so the idea of compiling from a single root would make no sense.
    Please do not ask for code as refusal often offends.

    ** This space for rent **

  4. #4
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: My first impression

    Quote Originally Posted by gimbal2 View Post
    Typical questions one would ask when you brush over things with the minimal effort and don't take the time to dive in deeper.
    I don't have a computer at present and my Android phone won't allow me to paste here, I'm sorry.

  5. #5
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: My first impression

    I'm sorry, my laptop had to be left behind for strategic reasons, but fortunately my father was able to retrieve it.

    I don't think I have to deal with or accept insinuations that I'm not doing "real" projects ;-), I'm sorry too! :p.

    Please insult someone else. I think it is perfectly capable to have parts of your source broken when you are working on a subfeature, unless you go all the way and have versioning for every small thing you do, which I at present don't. I consider Git a real Biatch to work with. I haven't gone into Subversion yet but the documentation on Wikipedia at least was really bad. Compared to CVS, which was really good.

    Currently I'm just using Github for Windows on that project which is nothing more than checking in and out without anything fancy. I don't spend aeons documenting every change I make (which I used to do when working on Linux projects) so my commits are at present just huge.

    Also I may be in the process of reworking some class and throwing out what I'd call "old junk" without having tied up the remaining spaces. Still at the same time I'm developing a new feature that will take its place, but the new feature has its own testing class that I compile and run on its own. I was in the process of moving it into the old space, but was doing some 'refactoring' in the process. These are conditions that happen frequently, I guess. The old project (the existing thing) won't build in the meantime as I'm working to integrate the old and the new.

    I take heed of the fact that classes have many entry points when used in Tomcat and the like. I guess you could still have 'entry point' compilation, but then again, that doesn't work if you have a suite of disjuncted and individual unit tests everywhere?

    I was writing this earlier on my smartphone:

    I do not have the health to spend more time on this. It was already an incredible feat of strength for me to get this far. The documentation on the Maven site is terribly bad (or at least badly organized) - they speak first of Repositories before they explain anything else, which is completely nonsensical and counterproductive. The file format is not self-explanatory at all, I found the quickstart guide not through the site itself but through google, the commands for generating a test build are utterly complex, what more do you want me to say?

    Usually the quality of the documentation describes or decries the quality of the product. E.g. the wikipedia on Subversion (SVN) is terribly chaotic and all over the place as if the writers did not know what to explain.

    It is perfectly clear Maven is not a very good product. What can I help it?

    I just ordered a book on Maven, it's Introducing Maven by Balaji Varanasi. Maybe that will get me up to speed given the lack of help here ;-).

    To the other poster: thank you for the implicit answer that Maven can only compile all source files it finds.
    I stand by my statement that Maven is crap. I have almost finished reading the book I ordered. The XML source file format is not suited (NOT SUITED) to configuration files like that. At all. It is a document format, and configuration files are not documents. Not in that sense. It's so convoluted. Without a reference you cannot do anything in it. I'm constantly saying to myself, while reading that book, "How on earth was I supposed to learn something like this?". There are commands and tags that are completely unknowable without some reference, like the commands required for generating archetype setups and outcomes.

    Any type of Linux based configuration file (such as that of Squid, the proxy server) would probably have been better. Anyway.

    I learned though one answer to my question. I asked, "Is it possible to include a second groupId?". The answer is that it is possible to include subprojects.

    But you have to use difficult commands, of type "mvn archetype:generate" to generate the root (or parent) with type "pom-root", and then from that directory you can create additional "modules" as usual. The parent POM file ends up with:

    Java Code:
    <packaging>pom</packaging>
    and

    Java Code:
    <modules>
      <module>name-of-first-module</module>
      <module>name-of-second-module</module>
    </modules>
    Whereas the child POM files automatically obtain:

    Java Code:
    <parent>
      <groupId>...</groupId>
      <artifactId>...</artifactId>
      <version>...</version>
    </parent>
    And that is all there is to it. You can now build the submodules by building the parent project.

  6. #6
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: My first impression

    I really think the convention over configuration is a bad idea. The reasons cited by the book were that it would reduce startup time with new programs and the time required to get acquainted with existing ones. All not very valid reasons unless you start a new project every day. And then the time required to "configure" would be on par with the time you spend doing your projects anyway.

    The whole of Java and the whole of the Maven directory tree is very small and simple. It takes no genius to guess what's what and any customized directory tree anyone might have doesn't take an aeon to traverse. I really don't see the benefit of "convention over configuration" when the convention is not to your liking. For instance, when you don't have tomcat directories and all.

    It is really forcing everyone to the same standard, which is always bad. And for little reasons. All in all it seems like a very amateurish program.

    All the same, I really don't know how to do subgoals within Maven. When I have something to compile that is a smaller way of doing something, I need another submodule within a parent project, to do it within Maven. There are also no options to use "compiler:compile" to just specify a target file or anything. This means I have to build my way of doing things around the way of doing things of Maven.

    And I don't like that. Currently I'm just making batch files to do individual compilation that just exposes into everything, but only the things I want. I could also compile single-target stuff that is components or libraries, it is not hard to identify an entry-point and I don't see the point of compiling entire source-trees. "A real project compiles everything". Yeah, right.

    I don't know how make it does, by the way (or cmake). I just think it is weird to compile everything you find. There might be leftover files you haven't cleared up yet but that aren't referenced by anything. Compiling then means cleaning up everything and having a perfect system before you can run anything. Not a good system, I think.

    It seems, If I am allowed to say so here, that Ant at least on this forum is quite dead. I do believe I'd like to read another quickstart guide on Ant, but yeah. No questions since 2014. I don't know what to do really. You can configure Maven to use different source trees but I haven't read that in my little book, I might need another book just to cover that ;-). It's the settings.xml, I guess. Not really what Maven is intended for and it still doesn't solve my problem. Of course I can use Maven to build the entire thing and then to keep using my shell scripts to do the smaller things, no problem. It's just that I won't have the same source tree.
    Last edited by Xen; 08-02-2015 at 08:28 PM.

  7. #7
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    13,541
    Rep Power
    26

    Default Re: My first impression

    Quote Originally Posted by Xen View Post
    Please insult someone else. I think it is perfectly capable to have parts of your source broken when you are working on a subfeature, unless you go all the way and have versioning for every small thing you do, which I at present don't. I consider Git a real Biatch to work with. I haven't gone into Subversion yet but the documentation on Wikipedia at least was really bad. Compared to CVS, which was really good.
    It's not an insult. It's an observation.

    I'm trying to point out why these things are as they are.

    Your view that CVS is good would be looked on with a degree of confusion in the industry, for example. It (and Subversion, frankly) doesn't handle the style of development that's been prevalent over the past decade. It was fine for a waterfall style, but it really falls apart with an agile environment, where reliable and swift branching and merging is required...hence Git. Though I will say that even for local dev work Git is very useful, for just the sort of throw away branching you seem to think is unnecessary.

    Quote Originally Posted by Xen View Post
    I stand by my statement that Maven is crap. I have almost finished reading the book I ordered. The XML source file format is not suited (NOT SUITED) to configuration files like that. At all. It is a document format, and configuration files are not documents. Not in that sense. It's so convoluted. Without a reference you cannot do anything in it. I'm constantly saying to myself, while reading that book, "How on earth was I supposed to learn something like this?". There are commands and tags that are completely unknowable without some reference, like the commands required for generating archetype setups and outcomes.
    And yet it used widely used.
    In any case, of course configuration files are documents. XML has been used for config for over a decade. Just look at Spring.

    Maybe you'd be more comfortable with Gradle?
    It's not as if there's a shortage of dependency management tools.


    Quote Originally Posted by Xen View Post
    I really think the convention over configuration is a bad idea. The reasons cited by the book were that it would reduce startup time with new programs and the time required to get acquainted with existing ones. All not very valid reasons unless you start a new project every day. And then the time required to "configure" would be on par with the time you spend doing your projects anyway.
    You're thinking in terms of a single person working on fairly small projects.

    These things were built for businesses and large scale development, over years, with a steady flow of developers, including contractors.
    This means any setup cost for the development environment is magnified.

    In addition, if everyone had a completely different structure how do you expect source control to function?

    Quote Originally Posted by Xen View Post
    All the same, I really don't know how to do subgoals within Maven. When I have something to compile that is a smaller way of doing something, I need another submodule within a parent project, to do it within Maven. There are also no options to use "compiler:compile" to just specify a target file or anything. This means I have to build my way of doing things around the way of doing things of Maven.
    Then find a different tool.
    Seriously.

    Quote Originally Posted by Xen View Post
    I could also compile single-target stuff that is components or libraries, it is not hard to identify an entry-point and I don't see the point of compiling entire source-trees. "A real project compiles everything". Yeah, right.
    I didn't say that. I said a real project doesn't have broken (uncompileable) bits.
    That's the sort of project Maven was built to handle.

    Quote Originally Posted by Xen View Post
    I don't know how make it does, by the way (or cmake). I just think it is weird to compile everything you find. There might be leftover files you haven't cleared up yet but that aren't referenced by anything. Compiling then means cleaning up everything and having a perfect system before you can run anything. Not a good system, I think.
    As far as Maven is concerned if it's in a project then it's supposed to be part of the project.
    To be honest, that's how pretty much any build environment works. Most of them are designed to fit in with the likes of Jenkins or Go, where a dead build is a no no.
    Please do not ask for code as refusal often offends.

    ** This space for rent **

  8. #8
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: My first impression

    Quote Originally Posted by Tolls View Post
    It's not an insult. It's an observation.
    Not really, it was condescending.

    Your view that CVS is good would be looked on with a degree of confusion in the industry, for example.
    No, I'm just saying that the documentation is at least clear. I know it is an old system and I'd probably never use it.

    It (and Subversion, frankly) doesn't handle the style of development that's been prevalent over the past decade.
    For some reason I like "real" branches as opposed to what Git does. It feels more solid. When you use Git from the command line, and you use all those tools and abilities, Git itself becomes like a University Master course. Using Git is not easy.

    It was fine for a waterfall style, but it really falls apart with an agile environment, where reliable and swift branching and merging is required...hence Git. Though I will say that even for local dev work Git is very useful, for just the sort of throw away branching you seem to think is unnecessary.
    When I was using Git on some source files (mostly Bash scripts I believe) I did try to use a lot of throw away branching as you term it. I tried to find my way around it but it was not easy. I settled for the time being on working in the (main) branch and then pushing my changes onto a Stash. Then I would pop the stash in a way that allowed me to select the bits and pieces that I wanted (for the current commit). After a while that got very pleasant as long as I didn't end up in trouble I didn't know how to fix. I also branched and then did the same to that branch. Then I could merge the branch into master. And sometimes I ended up in merge conflicts I couldn't understand, and which messed up the "perfection" of the commit log. Then I tried to fix the commit log, which ended me up in more trouble and nightmarish departures from normality ;-).

    I have often, in that period, accidentily thrown away files I had changed or edited or improved. I would do something and suddenly my changes were gone or some files were missing.

    I do not consider Git very failsafe and I do not consider it a form of backup at all.

    And yet it used widely used.
    Maven, yes. It seems rather so mundane and limited. I bet it is used a lot for enterprise work, but I don't consider it to be anything fancy up to this point. You select (enter) dependencies, it automatically downloads them. Great. Wonderful. Miracle. And it has a few built-in tasks (phases) that are nothing special. The phases are dependent on each other like those of Ant (if you wish). I mean, maybe the wonder of Maven starts to shine when you really start to configure it, but thus far (and in the introductory book I've read) if you take away the respository management there is not much left.

    I guess it is very helpful, and it seems that way, to be able to install repositories in your company network and upload in-company jars to it, with a cascase of internet-sourced and locally-sourced repositories in which you can also deploy your own jars if they are part of a larger network or system. Maybe it feels so clumsy because it's Java, but...

    I dunno. I expect better from an open source tool. For instance, it doesn't seem to be up to par with general Linux/Unix style command line parameters and log output. For example (...).

    Every plugin that is being called is overly verbose. It is hard to read. I don't have an example right now. The output formatting of the command line tool is not very well done. Well, whatver ?.

    In any case, of course configuration files are documents. XML has been used for config for over a decade. Just look at Spring.
    I must say that my experience with Ant is much better, if only because there is better documentation available (it seems). But the tags have to make sense. I think Ant uses XML the way it was meant to be used, with references from one tag to another and all that. Maven has MANY obscure tags that are not used or offered in default pom files. For instance, the documentation tells you that you can change the directory structure if you want, but then subsequently doesn't explain how to do it. When you start digging through all the possible tags, you come across <build><sourceDir>...</sourceDir></build>. It is not well documented and then you still don't know how to change it.

    I'm just saying that probably with a different source format the thing would be 1000x more readable and writable.

    I am glad to know though that Ant and Maven are entirely different beasts.

    Maybe you'd be more comfortable with Gradle?
    It's not as if there's a shortage of dependency management tools.
    I'll stick to Ant for a while ;-).

    You're thinking in terms of a single person working on fairly small projects.

    These things were built for businesses and large scale development, over years, with a steady flow of developers, including contractors.
    This means any setup cost for the development environment is magnified.

    In addition, if everyone had a completely different structure how do you expect source control to function?
    But the directory structure is nothing fancy and nothing big. It if was possible to configure it, not much would be lost. The first thing you expect in any config file of such measure is the definitions. Mostly any (Linux) software allows you to configure locations. If your company likes a certain build structure, fine, but it doesn't have to be determined by basically, essentially, one person who has decided it for everyone else.

    So of course if there was a single project, no matter how large or small, you would maintain one single directory structure.

    But people have different tastes. One size fits all is not really my thing. If you could configure Maven in a solid way then it would only add to the experience. I often hear complaints (read...) of utterly large and complex Ant build files. But what's the big deal?

    The basic setup of Ant is very minimal. I spent some 2 hours and now I am done. When my project grows, more things will enter the picture, but at my own pace.

    I personally needed something that will grow with me.

    Then find a different tool.
    Seriously.
    I'm not done exploring Maven yet (and Gradle, for that matter). I am just astounded by how bad it really is. Have to speak up about it ;-). Somewhat.

    I just got a book on Ant in the mail, but they are unwilling to bring it to my room (I'm in a wheelchair).

    I didn't say that. I said a real project doesn't have broken (uncompileable) bits.
    That's the sort of project Maven was built to handle.
    My project is a real project. There you go again ;-).

    I tend to like it this way. And besides, your statement is logically impossible.

    Any type of change will momentarily render the source code uncompilable. If the change is small, then the uncompilable phase will be short. I often work for hours and hours without compiling. Then when my work is done I start to compile and work out the obvious bugs. The mistakes and the type errors. Then enventually when everything compiles it often works straight away. Yes of course this is a single person project at this point. In a "real" project (that means, a multi-person or bigger project) -- (but size has nothing to do with 'reality') you would branch and do that sort of work in a branch, but then the branch wouldn't compile for a while.

    I don't even know how building and source control work together. I guess you have dedicated jobs for building the master branch. In Git if you branch to something else, your whole working directory is changed.

    I used to work on scripts and the most recent version of the script was always in the working directory. But if I then branched or did anything, my scripts and symlinks would cease working. I prefer to branch in a different directory tree, but didn't know yet how to do that.

    As far as Maven is concerned if it's in a project then it's supposed to be part of the project.
    To be honest, that's how pretty much any build environment works. Most of them are designed to fit in with the likes of Jenkins or Go, where a dead build is a no no.
    So maven is only meant for "building master branches" and making sure all tests etc. comply and complete? And subsequently updating all the repos with the latest versions, etc. The sort of stuff you don't really do manually and/or stuff that doesn't really coincide with doing anything risky or big in the sense that bigger systems of many many components can't ever break.

    In other words -- the stuff you do in a branch -- Maven is not meant for that?

  9. #9
    jim829 is offline Senior Member
    Join Date
    Jan 2013
    Location
    Northern Virginia, United States
    Posts
    6,226
    Rep Power
    13

    Default Re: My first impression

    Quote Originally Posted by Xen View Post
    Not really, it was condescending.
    Tolls very rarely insults anyone nor is he condescending. His statement was neither. Now, there are others on this forum who will let you know very quickly when you say something stupid or make a statement without backing it up or who just disagree with you (I have been on the receiving end quite a few times). A prerequisite for participating in this forum not mentioned in the FAQ is to have thick skin.

    Regards,
    Jim
    The JavaTM Tutorials | SSCCE | Java Naming Conventions
    Poor planning on your part does not constitute an emergency on my part

  10. #10
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: My first impression

    Quote Originally Posted by jim829 View Post
    Tolls very rarely insults anyone nor is he condescending. His statement was neither. Now, there are others on this forum who will let you know very quickly when you say something stupid or make a statement without backing it up or who just disagree with you (I have been on the receiving end quite a few times). A prerequisite for participating in this forum not mentioned in the FAQ is to have thick skin.

    Regards,
    Jim
    :). That's allright.

    I would just like to be a "real project" person myself ;-). No matter the fact that I'm working alone and have never done any sense of professional development. I'm a bit behind as well, I wanted to do this stuff a year ago (almost) but I got ... locked up in places.

    Thanks for your reply Jim.

  11. #11
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    13,541
    Rep Power
    26

    Default Re: My first impression

    Quote Originally Posted by Xen View Post
    Not really, it was condescending.
    It wasn't intended as such.
    :)

    Quote Originally Posted by Xen View Post
    No, I'm just saying that the documentation is at least clear. I know it is an old system and I'd probably never use it.
    Git has the (for me quite good) Git Book for download.

    Quote Originally Posted by Xen View Post
    For some reason I like "real" branches as opposed to what Git does. It feels more solid. When you use Git from the command line, and you use all those tools and abilities, Git itself becomes like a University Master course. Using Git is not easy.
    I won't deny that it's a shift in thinking from the CVS-style of code management.
    Took me a while, but I had the advantage of already being quite dissatisfied with how SVN was handling things in an agile environment, and a "it can't be any worse" view.

    Of course, typically, I'm currently stuck in a (largely) SVN environment. The joy of contracting.

    Quote Originally Posted by Xen View Post
    <snip Git problems for brevity>
    I do not consider Git very failsafe and I do not consider it a form of backup at all.
    That sounds to me like you were fighting the tool.
    The branching section of the Git book might help.

    No tool is going to be fail safe.
    You can easily muck up SVN, and it's merging from multiple sub branches is notoriously poor.

    Quote Originally Posted by Xen View Post
    You select (enter) dependencies, it automatically downloads them. Great. Wonderful. Miracle. And it has a few built-in tasks (phases) that are nothing special. The phases are dependent on each other like those of Ant (if you wish). I mean, maybe the wonder of Maven starts to shine when you really start to configure it, but thus far (and in the introductory book I've read) if you take away the respository management there is not much left.
    Dependency management was what it was built for.
    There were already plenty of build tools, so that aspect was not the novelty.

    Quote Originally Posted by Xen View Post
    I dunno. I expect better from an open source tool. For instance, it doesn't seem to be up to par with general Linux/Unix style command line parameters and log output. For example (...).
    Fair point on the logging...:)

    Quote Originally Posted by Xen View Post
    Every plugin that is being called is overly verbose. It is hard to read. I don't have an example right now. The output formatting of the command line tool is not very well done. Well, whatver ?.
    Can't really blame the plugins on Maven, though.

    Quote Originally Posted by Xen View Post
    I often work for hours and hours without compiling.
    That could be your problem.
    You might be throwing too much code at the wall before building.

    I'm going to assume this is not a Test-Driven project...:)
    You can get Maven to do a non-test build.


    Quote Originally Posted by Xen View Post
    So maven is only meant for "building master branches" and making sure all tests etc. comply and complete? And subsequently updating all the repos with the latest versions, etc. The sort of stuff you don't really do manually and/or stuff that doesn't really coincide with doing anything risky or big in the sense that bigger systems of many many components can't ever break.

    In other words -- the stuff you do in a branch -- Maven is not meant for that?
    I think you misunderstand.
    A branch has to build if you want to actually run it.
    That's all I'm saying.

    Locally, in the sorts of environments I work in, a feature branch may be bust (usually duff tests, are failing on quality).
    Intermediate check ins might be broken (again, we're talking the tests and side issues, not that it won't start up).
    The "proper" build runs off the trunk, so when feature is merged back into the trunk it should all function, otherwise the automated build system will choke...
    Please do not ask for code as refusal often offends.

    ** This space for rent **

  12. #12
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: My first impression

    Quote Originally Posted by Tolls View Post
    It wasn't intended as such.
    :)
    Fine, I'll go cry in a corner :P. Lol. No worries.

    Git has the (for me quite good) Git Book for download.
    Pff, more to read. I have the time to read now but I spend all my time coding these last few days.

    I won't deny that it's a shift in thinking from the CVS-style of code management.
    Took me a while, but I had the advantage of already being quite dissatisfied with how SVN was handling things in an agile environment, and a "it can't be any worse" view.
    I'm not sure I want agile environments, maybe that's my issue :p. When I read about "extreme programming" I think "ugh... :(".

    Of course, typically, I'm currently stuck in a (largely) SVN environment. The joy of contracting.
    Hmm, SVN still seems nice to me. But just reading Wikipedia made it clear there were a lot of issues with it.

    That sounds to me like you were fighting the tool.
    The branching section of the Git book might help.
    I was mostly just using commands I didn't fully understand. I'm accustomed to just starting to use a program or tool and it never really bugs me out, but Git does. I can use any Linux tool and learn as I go, only taking in as much as I can handle. But Git....

    It is like you need a complete understanding of its branch/head/commit/whatever structure before you can know in part what to do.

    I even downloaded a (short) tutorial. No, I printed it. That's what I mean. I printed a tutorial off of atlassian.com. It's the first Google hit. On "git tutorial". I printed it and read it, was not even easy to get it printed.

    It took me, for instance, a long while to get accustomed to how the rebasing thing works. You rebase a later commit onto an earlier commit but you cannot rebase onto the project root / root commit. So then there are scripts you can find on SO that will rebase the entire thing onto an empty root, and if you don't mess up the command you can then rebase something onto the real root which is now the second commit, and git will then automatically clear the root commit again (that is now empty) so you end up with what you want.

    Changing commits in the past... Sometimes you have a commit that is a combination of many things and as you are clearing up the commit log for brevity and clarity, you may want to split some commit. So you go back to the commit prior to the commit you want to split, you reset the changes from there, then you re-add some of the changes you want in the first commit, then you re-add the other changes and make your second commit. Then you need a way to replay or fast-forward the rest of the commits that came after. And I've done all of that at some point but I still don't know how to get back to the real HEADHEADHEAD. Maybe rebase --continue, or that is something different entirely. ;-).

    I like rewriting history yeah. If you are going to document everything you do, at least have a way to improve, fix, or change that. It really makes no sense to have a history that is just sitting there no matter how verbose or convoluted. The whole idea of any system is that you learn as you go,

    but if you start a project in Git and you are not yet up to speed with it or not experienced, it will mean you mess up a lot. So you need a way to go back, after all this is your project you are starting, you want the start to be good and not messy.

    No tool is going to be fail safe.
    You can easily muck up SVN, and it's merging from multiple sub branches is notoriously poor.
    Right, that's probably not a fault or defect of the main architecture but more the software itself?

    Dependency management was what it was built for.
    There were already plenty of build tools, so that aspect was not the novelty.
    Okay. "Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information." Not a word about dependency management. "We wanted a standard way to build the projects, a clear definition of what the project consisted of, an easy way to publish project information and a way to share JARs across several projects." That sounds more like it. They were in a specific environment where they had trouble integrating various projects that each had their own structures, so they wanted a default standard structure that would allow them to harmonize or homogenize their projects in order to automate the whole damn thing.

    It could have been done in a different way of course. All you require is for the "Maven" to learn about project structure and information, that way it could esasily have harmonized disparate structures. After all, every build structure has the same components and concepts.

    But now I can understand why there is such an emphasis on project information in the POM files. It is really intended for centralized management. They want all the projects to register themselves with a central build server. It's pretty shabby and poor, but I guess it can work. Man, if I just invented that I could have turned it into something so beautiful ;-D.

    But I've never worked in a company. At least not in any company that was worth the name company :p.

    Fair point on the logging...:)
    Thanks :).

    That could be your problem.
    You might be throwing too much code at the wall before building.
    Well, if you create an entire new class structure, such as starting with the interface you'd like something to have to the rest of your program, and then seeing how to accomplish that interface, it might mean you are reworking, or creating new things, for a long time before it makes sense to compile.

    Generally after creating something like that ---- I mean, this is also the issue with unit tests.

    I can easily incorporate something into my main program and I will know where to put it and how it works. But how are you going to accomplish the same in a unit test?

    I mean, for instance, my StateMachine I can test. I can test a new definition for it, a simple one, or I can just use the existing definition - but there you go again, now I am not only testing the StateMachine but also the definition for ANSI tokens I have for it.

    It is just much easier to test and debug the application as a whole because it requires very little extra.

    Of course I *do* write smaller programs to test the library features. So there is a StateMachineTest that I was using to build up the StateMachine and give it a definition before incorporating it into my larger program. Then after a while I set about creating the interface (proper interface) between the as-then-yet-defunct stream reading classes (ANSIReader, in my case, for what it's worth) and the new library. I imagined a Tokenizer and how it should function, and then went about matching the StateMachine to the Tokenizer in such a way that the Tokenizer was an easy, small and elegant interface to the StateMachine.

    I just went and copied/took/ranted/rented a lot of ideas from that Squirrel Foundation FSM. Which is an inspiration.

    Finally when the Tokenizer was finished I went about designing its exact interface to the ANSIReader. I realized the ANSIReader was actually only interested in a few states, so I went about discovering and revealing and portraying those states to it. E.g. "completed()" and "busy()" and those were all the states I needed.

    My StateMachine is still butt ugly as far as I'm concerned. But it is getting somewhere I guess.

    Let me divulge some of the class structure. This is getting way off topic but whatever, it's my thread :p. And I guess it is illustrative as to coding style and Maven.

    The state machine is composed of a StateMachineBuilder that can be instantiated to provide (and start building with it) a state transition matrix and all that. States (an enum) and Events (an enum) are offered to it with its constructor. [[This didn't use to be like this of course, it initially was just one class.]]. The MachineBuilder can be used to generate a Machine that will use the MachineBuilder as its definition. So everything that is instantiated per-machine goes into Machine, everything else (static as it were) goes into the MachineBuilder. Eventually I realized I could just subclass the MachineBuilder instead of using it as an object. So now a simple usage is like:

    Java Code:
    public class MachineTest extends MachineBuilder {
        enum State {
            A, B, C
        }
        enum Event {
            X, Y, Z
        }
    
        class Context {
            ...
        }
    
        public MachineTest() {
            super(State.class, Event.class);
    
            from(State.A).to(State.B).on(Event.X).perform( new AbstractAction() {
                public void perform(Object c) {
                    Context context = (Context)c;
                    context. .....;
                }
            });
    
            onExit(State.A).perform ( .... );
        }
        
        public static void main(String[] args) {
            MachineTest mt = new MachineTest();
            Machine m = mt.instantiate(State.A);
    
            m.fire(Event.X, null); // will cause nullpointerexception in perform(Object) since we have no context.
            System.out.println(m.state());
        }
    }
    Just imagine that as part of the change, or the development, you also create a number of other classes. You may have classes like Transition and Event and they can't compile until they are subtly suited within the larger framework. It just takes a while to get a structure up and running that will compile as a whole without having any decidated 'unit tests' to test individual classes - that are depedent on other classes in any case.

    Now what we end up with here is that ANSIReader.filter() calls Tokenizer.feed() and Tokenizer.completed() and Tokenizer.busy() and Tokenizer.obtain(). The Tokenizer calls ANSIMachineBuilder.createNew() and Machine.fire() and Machine.state(). That's pretty much all it does (and some .addFlag() that I can't get my head around).

    The StateMachine has two input Events: "INPUT" and "READOUT". Input is always accompanied by a char value as well as a larger Context that contains the code required to build the result objects. "READOUT" is an event that resets the Machine (triggers a state change from FINAL to NONE) and clears any Context data that might have accumulated. In addition to clearing the flag that I have.

    I still don't know how to do that flag. Currently my machine is aware of the flag, but in actual effect it doesn't need to be at all and it can be just part of the context; the flag is registered with the machine but not ever really used.

    So you can see when I am like writing 4-5 classes at the same time, it makes no sense to compile until the structure is ready. Then, when it compiles (and the compile bugs are out) usually it runs straight away withour error.

    The biggest bug I've had yesterday was that I had forgotten to give a custom class a hashCode() and hence the Hashtable / HashMap wouldn't function. It is pretty remarkable and odd to see that HashMap.containsKey() or HashMap.get() simply doesn't work.

    I had even written a unit test for that, which is how I discovered it.

    I'm going to assume this is not a Test-Driven project...:)
    I'm trying to get into that. But it is hard to write good tests because:

    • JUnit favours small tests in small methods with a few or a single assert
    • Given small methods you cannot build up bigger class/object structures that allow for more interesting tests
    • Testing is often a history, or a proceeding. You test one thing, add more changes, test again.
    • I'm having to run all my tests now on basically the same class/object structure.


    It is often impossible to carry on the build-up of one test method to another, since all tests are run in their own instance of the test class. This destroys the story aspect of what I want to do and enforces a vast amount of build-up for even the smallest of tests. At the same time the buildup you require might be stuff you ALSO need to test, but you can't, because if you do, you won't have the full buildup for more complex tests in the same class. So now you need to write extra test classes for each "step in the way" much of which then contains duplicate code. So what you are left is is to just build up something big and then try to test various features of it, to see if all sizes are correct and all booleans fit the curve, and what not. I don't like it very much..... :-/ ?.

    You can get Maven to do a non-test build.
    Oh. I thought that Test was mandatory part of the Build life cycle. Not that it matters. I run tests now, but I'm at pains to develop more. In any case, I believe those kind of tests are only meant to prevent regressions in existing code?

    It's not the best way to debug an application.

    I think you misunderstand.
    A branch has to build if you want to actually run it.
    That's all I'm saying.
    Of course. But we are developing. That means we are taking a step, which means that momentarily we are only standing on one foot. And we are slightly out of balance until our foot comes down again and finds solid ground once more ;-). Every step we take, whether on level floor or a stairs, unbalances us.

    Locally, in the sorts of environments I work in, a feature branch may be bust (usually duff tests, are failing on quality).
    Intermediate check ins might be broken (again, we're talking the tests and side issues, not that it won't start up).
    The "proper" build runs off the trunk, so when feature is merged back into the trunk it should all function, otherwise the automated build system will choke...
    I understand.

  13. #13
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: My first impression

    To get back to Maven: I just read part of the book I have that says how Maven can be used to generate a "site".

    What it basically means is that you have various reporting plugins such as Surefire and JavaDoc that automatically chime in with the directory structure and register with the Site life cycle and hence easily and without much configuration can produce a new website with test results as well as the project's class documentation.

    Which is actually quite nice and I think I want to use it :p.

    Right now my JUnit does generate output .TXT files but they are a pain to open and read. I wouldn't mind a surefire report if I needed that; would enable me to read test results and errors in a browser. Quite nice. Currently....

    [I just read all my compiler output in a default cmd window. jEdit's console doesn't quite cut it. PowerShell is a horror from what I can see. You would think that being advances and all with all our software we'd have better means of reading compile output, but there it is. Even just a browser with a web-report would help me.]

  14. #14
    Xen
    Xen is offline Member
    Join Date
    Jan 2015
    Posts
    86
    Rep Power
    0

    Default Re: My first impression

    I'm actually gravitating towards the Maven directory tree now.

    As time goes on...

    /src/main
    /src/test
    /bin/main
    /bin/test
    /lib
    /report
    /tmp


    In Maven there are only two root/main directories because libraries are placed in a Maven directory and all output is put into /target. I don't know where I will end up with, but it is going along nicely.

Similar Threads

  1. How can I see the impression of the Garbage Collector?
    By Zamioculcas in forum New To Java
    Replies: 3
    Last Post: 04-01-2011, 02:34 PM
  2. Biometric Thumb Impression Authentication for login in jsp
    By kishore rajkumar in forum JavaServer Pages (JSP) and JSTL
    Replies: 1
    Last Post: 08-12-2009, 02:30 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •