issues with the recent build changes

[Brett Porter <br...@apache.org>]

Hi,

I have a couple of questions about the way the recent change to the
build/versions was done.

For the versions - the removal of the SNAPSHOT was perhaps not correct. Say
someone builds this and gets ldap-common-0.2.0.jar. Then they change something
and build again to get... ldap-common-0.2.0.jar. Which is the latest? If there's
a newer one in the remote repository - but Maven won't download it.

Let me know if you think differently, but the process we tend to encourage with
Maven is:
- start with 0.1-SNAPSHOT
- build using this
- release 0.1, tag SCM
- update project version when start work on 0.2-SNAPSHOT
- and so on

If 0.2.0/0.8.0 for the various artifacts are to eventually become "official"
releases, I suggest changing to the other technique so the official release does
not get confused with the version you built from CVS a week ago :)

The other thing was the names of subdirectories in projects. In eve, there is
main
plugin (renamed from maven-eve-plugin)
shared
...

These don't match the artifactId of the projects they contain, which introduced
the need for a module.name property to be able to reference them correctly.
Is this necessary? It would be nice to name subdirectories consistently with the
artifactId.

Cheers,
Brett

Re: issues with the recent build changes

[Alex Karasulu <ao...@bellsouth.net>]

Brett Porter wrote:

>Hi,
>
>I have a couple of questions about the way the recent change to the
>build/versions was done.
>
>For the versions - the removal of the SNAPSHOT was perhaps not correct. Say
>someone builds this and gets ldap-common-0.2.0.jar. Then they change something
>and build again to get... ldap-common-0.2.0.jar. Which is the latest? If there's
>a newer one in the remote repository - but Maven won't download it.
>
>Let me know if you think differently, but the process we tend to encourage with
>Maven is:
>- start with 0.1-SNAPSHOT
>- build using this
>- release 0.1, tag SCM
>- update project version when start work on 0.2-SNAPSHOT
>- and so on
>  
>
Ok I've got -SNAPSHOT appended to all the versions now.  WRT to changing 
names back I wanted to wait until you responded to my last email.  I'll 
make a very clear anouncemtn about blowing away the local maven repo 
jars in incubator-directory.

Alex

Re: issues with the recent build changes

[Berin Loritsch <bl...@d-haven.org>]

Brett Porter wrote:

>Hi,
>
>I have a couple of questions about the way the recent change to the
>build/versions was done.
>
>For the versions - the removal of the SNAPSHOT was perhaps not correct. Say
>someone builds this and gets ldap-common-0.2.0.jar. Then they change something
>and build again to get... ldap-common-0.2.0.jar. Which is the latest? If there's
>a newer one in the remote repository - but Maven won't download it.
>  
>

May I interject something here?  I really hope we never run into a 
situation where we release
0.2.0 on the remote repository and then update the JAR and re-release it 
with the same version
number.  Such an action would be wrong on many levels.  A version is a 
marked snapshot of
the library that was determined to work as expected.  If the contents of 
that version change, then
the expectations change--that is bad.  Which is why we increment versions.

The only time a version may change in a local repository is when we are 
building potential
new libraries to use in the overall system--but aren't quite sure.  
People are lazy so they either
forget to change the version ID to SNAPSHOT or increment versions as 
necessary.  But that's
the local repository.  What is on the remote one should remain the same.

>Let me know if you think differently, but the process we tend to encourage with
>Maven is:
>- start with 0.1-SNAPSHOT
>- build using this
>- release 0.1, tag SCM
>- update project version when start work on 0.2-SNAPSHOT
>- and so on
>
>If 0.2.0/0.8.0 for the various artifacts are to eventually become "official"
>releases, I suggest changing to the other technique so the official release does
>not get confused with the version you built from CVS a week ago :)
>
>The other thing was the names of subdirectories in projects. In eve, there is
>main
>plugin (renamed from maven-eve-plugin)
>shared
>...
>
>These don't match the artifactId of the projects they contain, which introduced
>the need for a module.name property to be able to reference them correctly.
>Is this necessary? It would be nice to name subdirectories consistently with the
>artifactId.
>
>Cheers,
>Brett
>
>  
>


-- 

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
                - Rich Cook

Re: issues with the recent build changes

[Brett Porter <br...@apache.org>]

> I was just thinking... Subprojects like snickers and eve which generate 
> more than one jar prefixes the project name to the name of the 
> artifacts.  Like the artifactId may be snickers-ber but the project has 
> a ber directory for the maven project underneath.  Then what do I do for 
> things like eve/trunk/eve which I have created to build the final full 
> executable jar with all deps inside? Should it be eve-eve or just plain 
> old eve for the artifactId.  BTW I renamed 'eve' to 'main' but still 
> produce an eve-0.8.0-.... from it.

No, I wouldn't go for "eve-eve". "eve" is fine for an artifactId. Basically, you
just need to meet this criteria when picking an artifactId:
- needs to make sense standalone as it is the jar name
- needs to be unique within the group

Maven doesn't impose any particular restriction on them.

> If the name of the directory from the artifact is off anywhay what 
> difference does it make?

Maven typically doesn't care (as you can see - everything is building fine at
the moment). There is talk of using this to facilitate some functionality in the
future, though not requiring it.

It does make it easier to find the location of a particular artifact in a big
source tree that you are unfamiliar with though :)

I haven't had an answer back from the gump folk - there's a small chance gump
will not like the discrepancy, but that's probably just my misunderstanding.

HTH!

Cheers,
Brett

Re: issues with the recent build changes

[Alex Karasulu <ao...@bellsouth.net>]

Alex Karasulu wrote:

> Brett Porter wrote:

<snip/>

>> The other thing was the names of subdirectories in projects. In eve, 
>> there is
>> main
>> plugin (renamed from maven-eve-plugin)
>> shared
>> ...
>>
>> These don't match the artifactId of the projects they contain, which 
>> introduced
>> the need for a module.name property to be able to reference them 
>> correctly.
>> Is this necessary? It would be nice to name subdirectories 
>> consistently with the
>> artifactId.
>>  
>>
> Ok I just liked the shorter names plus there was an eve directory 
> which matches the working directory eve creates by default.  I will 
> revert this back so we're inline with Maven.  I have the feeling this 
> will save us some work later somewhere.

I was just thinking... Subprojects like snickers and eve which generate 
more than one jar prefixes the project name to the name of the 
artifacts.  Like the artifactId may be snickers-ber but the project has 
a ber directory for the maven project underneath.  Then what do I do for 
things like eve/trunk/eve which I have created to build the final full 
executable jar with all deps inside? Should it be eve-eve or just plain 
old eve for the artifactId.  BTW I renamed 'eve' to 'main' but still 
produce an eve-0.8.0-.... from it.

If the name of the directory from the artifact is off anywhay what 
difference does it make?

Alex

Re: issues with the recent build changes

[Alex Karasulu <ao...@bellsouth.net>]

Brett Porter wrote:

>For the versions - the removal of the SNAPSHOT was perhaps not correct. Say
>someone builds this and gets ldap-common-0.2.0.jar. Then they change something
>and build again to get... ldap-common-0.2.0.jar. Which is the latest? If there's
>a newer one in the remote repository - but Maven won't download it.
>  
>
Ahh ok I see.  I was geting ready for the release before tagging the 
repository but there is time before the release does happen.  In this 
time you're right we can totally get out of sync.  So basically I put 
snapshot at the end of the version and this will do it eh.  Ok I'll 
revert back.

>Let me know if you think differently, but the process we tend to encourage with
>Maven is:
>- start with 0.1-SNAPSHOT
>- build using this
>- release 0.1, tag SCM
>- update project version when start work on 0.2-SNAPSHOT
>- and so on
>
>  
>
This is exactly what I was thinking but totally lost sight of 
SNAPSHOT'ing until right after a release.

>If 0.2.0/0.8.0 for the various artifacts are to eventually become "official"
>releases, I suggest changing to the other technique so the official release does
>not get confused with the version you built from CVS a week ago :)
>  
>
Yep yep sorry.  I will fix this right away and blow away what's there.  
Plus I guess everyone will need to clear out their local copies of 
incubator-director jars. 

>The other thing was the names of subdirectories in projects. In eve, there is
>main
>plugin (renamed from maven-eve-plugin)
>shared
>...
>
>These don't match the artifactId of the projects they contain, which introduced
>the need for a module.name property to be able to reference them correctly.
>Is this necessary? It would be nice to name subdirectories consistently with the
>artifactId.
>  
>
Ok I just liked the shorter names plus there was an eve directory which 
matches the working directory eve creates by default.  I will revert 
this back so we're inline with Maven.  I have the feeling this will save 
us some work later somewhere.

Thanks for the feedback.  I'll make the corrections tonight.

Alex