You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Aristedes Maniatis <ar...@ish.com.au> on 2009/12/26 03:02:40 UTC
maven dependency issues
I've been spending a little time trying to work out the issues with maven that require Cayenne to be installed. I have some hunches, but would like to ask some questions to make sure I don't mess things up:
1. The top level pom (cayenne-parent) has a module "framework". The framework (cayenne-framework-parent) pom has a parent "cayenne-parent" and has a module "cayenne-tools". The cayenne-tools pom has a parent "cayenne-parent" rather than "cayenne-framework-parent". That is, modules represent the children, and parent should be the reverse of that. But in this case, the parent points to the grandparent.
2. Why are there inconsistent groupids? org.apache.cayenne.parents and org.apache.cayenne. Can we just have one groupid for the entire project?
3. Why is the version in the 3.0 poms still referring to 3.0-SNAPSHOT, rather than 3.0-BETA1? And why do we have to change that in 20 files? Can't maven inherit from the top pom somehow?
4. Will changing the above things be disruptive to the maven universe now that artifacts have already been deployed?
Because I still don't understand why maven does things a particular way, I could be off base, but my guess is that fixing (1) will resolve a few problems [1].
Ari
[1] 'install' is always required for every build if you are going to get reproducible results, and I just can't get Clover to work.
--
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: maven dependency issues
Posted by Andrey Razumovsky <ra...@gmail.com>.
http://jira.codehaus.org/browse/MJAVADOC-274
2009/12/27 Andrey Razumovsky <ra...@gmail.com>
>
> or why this isn't working:
>>
>> http://hudson.zones.apache.org/hudson/view/Cayenne/job/Cayenne-doc30/
>>
>>
> This is downside of our upgrade to newer javadoc plugin, to fix that you
> need to make PlaceHolder class in jdk-1.6-unpublished public - I've done
> that on trunk only
>
--
Andrey
Re: maven dependency issues
Posted by Andrey Razumovsky <ra...@gmail.com>.
> or why this isn't working:
>
> http://hudson.zones.apache.org/hudson/view/Cayenne/job/Cayenne-doc30/
>
>
This is downside of our upgrade to newer javadoc plugin, to fix that you
need to make PlaceHolder class in jdk-1.6-unpublished public - I've done
that on trunk only
Re: maven dependency issues
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 29/12/09 2:40 AM, Andrus Adamchik wrote:
> On Dec 28, 2009, at 5:38 PM, Andrey Razumovsky wrote:
>
>> Not sure this will be of help, but is it OK that tutorial POM does not
>> have
>> a parent while it is referenced by "tutorials"?
>
> It has no parent intentionally for the reason that I mentioned, and yes,
> it is one possible cause why it fails (not that it makes any sense).
I know that fixing the maven version has moved us forward, but the overall install/parent issues are still there. And I just saw this email from the maven people, wanting ASF projects to use this as a parent:
http://svn.apache.org/viewvc/maven/pom/trunk/asf/pom.xml?revision=893969&view=markup
I'm not sure there is huge benefit, although perhaps we could learn from some of the interesting things in their POM.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: maven dependency issues
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Dec 28, 2009, at 5:38 PM, Andrey Razumovsky wrote:
> Not sure this will be of help, but is it OK that tutorial POM does
> not have
> a parent while it is referenced by "tutorials"?
It has no parent intentionally for the reason that I mentioned, and
yes, it is one possible cause why it fails (not that it makes any
sense).
> Also, what is maven version we use on Hudson?
Yep. Another possible cause of discrepancy. I was going to look at
this once I get a bit more time.
Andrus
Re: maven dependency issues
Posted by Andrey Razumovsky <ra...@gmail.com>.
2009/12/28 Andrus Adamchik <an...@objectstyle.org>
>
> 6.
>> /zonestorage/hudson/home/hudson/hudson/jobs/Cayenne-30/workspace/cayenneTestConnection/HSQLDB/jdk/JDK
>> 1.6
>> (latest)/STABLE-3.0/tutorials/tutorial/src/main/java/org/apache/cayenne/tutorial/persistent/auto/_Painting.java:[3,25]
>> cannot find symbol
>> Is this the same problem or something else? Why can't it find the Cayenne
>> code in the same project? Why do these sorts of problems haunt us?
>>
>
> This is what I need to figure out.
>
> Andrus
>
Not sure this will be of help, but is it OK that tutorial POM does not have
a parent while it is referenced by "tutorials"?
Also, what is maven version we use on Hudson?
--
Andrey
Re: maven dependency issues
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Dec 28, 2009, at 10:41 AM, Andrus Adamchik wrote:
>
> On Dec 28, 2009, at 3:55 AM, Aristedes Maniatis wrote:
>
>> 2. If we want to avoid some ongoing pain and hassle, we need to
>> remove the need to 'install' every module. That will probably fix
>> Clover as well. To me that seems straightforward and if that means
>> some people need to add one more pom to their project, well they
>> should either suck it, complain to maven developers or use another
>> build tool. At the same time I'd move everything into one namespace
>> for simplicity.
>
> IIRC the only reason install is needed is because we have maven
> plugins built, that are themselves used during the build (build-
> tools). For everything else install is not needed. So the problems
> are likely elsewhere.
Although I also need to test whether aggregate modules require an
install to be used in itests (IIRC for convenience we are not using
those as dependencies , but we really should).
>> To me that seems straightforward and if that means some people
>> need to add one more pom to their project, well they should either
>> suck it, complain to maven developers or use another build tool
So the only problem you are having with install is Clover
configuration? Then I'd rather we drop Clover :-) Seriously, I think
we can resolve all these issues. I just don't understand what problems
install is causing?
Andrus
Re: maven dependency issues
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Dec 28, 2009, at 11:19 AM, Aristedes Maniatis wrote:
> No, I think we need install because none of the modules are able to
> build against other modules since they can't 'find' each other.
> Since the parent references are fictional, maven is unable to
> traverse the build tree and figure out how all the code relates to
> each other.
As far as I know Maven's in-process "reactor" allows projects to
reference other not installed projects from the same build. Maven has
evolved a lot lately though, so I may have some dated assumptions on
the default command-line flags. The fact that the tutorial build is
failing on Hudson, but not on my machine may confirm that there's
something different about "mvn" now (your item #6). I see there's a
bunch of new reactor-related switches in mvn.
> 6. /zonestorage/hudson/home/hudson/hudson/jobs/Cayenne-30/workspace/
> cayenneTestConnection/HSQLDB/jdk/JDK 1.6 (latest)/STABLE-3.0/
> tutorials/tutorial/src/main/java/org/apache/cayenne/tutorial/
> persistent/auto/_Painting.java:[3,25] cannot find symbol
> Is this the same problem or something else? Why can't it find the
> Cayenne code in the same project? Why do these sorts of problems
> haunt us?
This is what I need to figure out.
Andrus
Re: maven dependency issues
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 28/12/09 7:41 PM, Andrus Adamchik wrote:
>
> IIRC the only reason install is needed is because we have maven plugins
> built, that are themselves used during the build (build-tools). For
> everything else install is not needed. So the problems are likely
> elsewhere.
No, I think we need install because none of the modules are able to build against other modules since they can't 'find' each other. Since the parent references are fictional, maven is unable to traverse the build tree and figure out how all the code relates to each other.
> So the only problem you are having with install is Clover configuration?
> Then I'd rather we drop Clover :-) Seriously, I think we can resolve all
> these issues. I just don't understand what problems install is causing?
Some of these may be real, and some of these just my frustration after spending too much time on this stuff...
1. When you build by hand and forget to run 'install' it is possible that you'll end up with an invalid build. This is dangerous for the release process in particular.
2. Hudson needs to install for every build now (that is, once we have say 10 databases to test against, 20 times it needs to install (1.6 and 1.5 multiplied against all the databases). This was the reason for the failure last week just after you did a bit of refactoring... all the Hudson builds started failing. I added "install" to them all now to get them to work.
3. Clover doesn't work. Possible all similar tools (findbugs, etc) will have similar problems. Not sure yet.
4. It wasted hours of my time because I couldn't see what was happening with the code I was working on, but that code wasn't being used, the 'installed' version was. Partly that is my own ignorance of maven: I'm not used to installing being a critical part of the build process.
5. It isn't the standard maven way and may well break stuff in the future. Certainly confuse people who expect that 'parent' and 'modules' in the pom make sense in the usual way. And I still don't quite understand why the particular groupids are named what they are.
6. /zonestorage/hudson/home/hudson/hudson/jobs/Cayenne-30/workspace/cayenneTestConnection/HSQLDB/jdk/JDK 1.6 (latest)/STABLE-3.0/tutorials/tutorial/src/main/java/org/apache/cayenne/tutorial/persistent/auto/_Painting.java:[3,25] cannot find symbol
Is this the same problem or something else? Why can't it find the Cayenne code in the same project? Why do these sorts of problems haunt us?
I'll stop harping on this now. If there is no appetite for change, that's fine. I can cope. But I need help to get the Hudson builds working again. And I really think Clover would be of great benefit to locating areas of critical code which aren't tested.
Maybe if I feel enthusiastic about maven again I'll try refactoring all the poms and see what happens. It shouldn't take too long to try it out. But I'm going out now for a nice post-Christmas dinner and perhaps with enough red wine maven will reveal its secrets to me later tonight...
Regards
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: maven dependency issues
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Dec 28, 2009, at 3:55 AM, Aristedes Maniatis wrote:
> 2. If we want to avoid some ongoing pain and hassle, we need to
> remove the need to 'install' every module. That will probably fix
> Clover as well. To me that seems straightforward and if that means
> some people need to add one more pom to their project, well they
> should either suck it, complain to maven developers or use another
> build tool. At the same time I'd move everything into one namespace
> for simplicity.
IIRC the only reason install is needed is because we have maven
plugins built, that are themselves used during the build (build-
tools). For everything else install is not needed. So the problems are
likely elsewhere.
> 4. Once all the above is sorted, I'll get back to the goal of
> running tests against mysql, MSSQL, Oracle, etc.
>
> Andrus, I've added your user name (same as your svn user) to Hudson
> as an administrator. Let me know if you can't log in. And let me
> know if you change anything so I know not to change it back. We have
> four jobs: a pair for creating docs and a pair for running tests.
> They are split that way since the docs jobs are slow and don't need
> to run once per database type. We have two jobs tracking 3.0 and two
> tracking trunk. Clover builds properly now, instruments everything,
> but then doesn't find a single instrumented class. Findbugs I
> switched on to see what it would do, but I never got to finish
> configuring it.
Thanks, I will look at it a bit later.
Andrus
Re: maven dependency issues
Posted by Andrus Adamchik <an...@objectstyle.org>.
Or we can actually delete the 1.6 module on 3.0 branch all together,
as it doesn't contain anything useful (or anything at all for that
matter).
(same for 3.1 I guess, but I was hoping we'll start using 1.6 features
at some point).
On Dec 28, 2009, at 10:08 AM, Andrey Razumovsky wrote:
> 2009/12/28 Aristedes Maniatis <ar...@maniatis.org>
>
>>
>> 1. If we want Javadocs for 3.0 then we need to hack that branch to
>> work
>> around the fact that maven can't build javadocs properly. Maybe we
>> need to
>> add this to the appropriate modules:
>>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-javadoc-plugin</artifactId>
>>
>> <configuration>
>> <skip>true</skip>
>> </configuration>
>> </plugin>
>>
>> Andrey, would that work around the maven bug you found?
>>
>>
> I'd prefer a simple workaround I did on 3.1 trunk.. just committed it.
>
> Also don't blame maven for its build order - you can see on the top
> of the
> log that it is correct. So the second problem is somewhere else..
Re: maven dependency issues
Posted by Andrey Razumovsky <ra...@gmail.com>.
2009/12/28 Aristedes Maniatis <ar...@maniatis.org>
>
> 1. If we want Javadocs for 3.0 then we need to hack that branch to work
> around the fact that maven can't build javadocs properly. Maybe we need to
> add this to the appropriate modules:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
>
> <configuration>
> <skip>true</skip>
> </configuration>
> </plugin>
>
> Andrey, would that work around the maven bug you found?
>
>
I'd prefer a simple workaround I did on 3.1 trunk.. just committed it.
Also don't blame maven for its build order - you can see on the top of the
log that it is correct. So the second problem is somewhere else..
Re: maven dependency issues
Posted by Aristedes Maniatis <ar...@maniatis.org>.
The bug Andrey reported doesn't have anything to do with Clover as far as I can tell. It looks like that one is that Clover can't find all the bits of code in order to assemble the results, probably because the modules don't correctly point to each other. That is just one reason I want to get rid of the hack which prevents us from using Maven as it is designed.
I don't like Maven at all, but I'm not advocating we change. I'm where you were 2.5 years ago: cursing it that it makes the simplest things so complicated. And of course it is so buggy, that you can't tell whether you've made a configuration error or maven is just broken. Fixing things on Hudson has the added enjoyment of waiting 2 hours to see if what you just did helped. If Tuscany is building ahead of you in the queue, then maybe 4 hours.
So here is where we are:
1. If we want Javadocs for 3.0 then we need to hack that branch to work around the fact that maven can't build javadocs properly. Maybe we need to add this to the appropriate modules:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Andrey, would that work around the maven bug you found?
2. If we want to avoid some ongoing pain and hassle, we need to remove the need to 'install' every module. That will probably fix Clover as well. To me that seems straightforward and if that means some people need to add one more pom to their project, well they should either suck it, complain to maven developers or use another build tool. At the same time I'd move everything into one namespace for simplicity.
3. Once javadoc building is working again I'll rewrite the scripts which suck them into the web site. That is very simple and will only take a few minutes.
4. Once all the above is sorted, I'll get back to the goal of running tests against mysql, MSSQL, Oracle, etc.
Andrus, I've added your user name (same as your svn user) to Hudson as an administrator. Let me know if you can't log in. And let me know if you change anything so I know not to change it back. We have four jobs: a pair for creating docs and a pair for running tests. They are split that way since the docs jobs are slow and don't need to run once per database type. We have two jobs tracking 3.0 and two tracking trunk. Clover builds properly now, instruments everything, but then doesn't find a single instrumented class. Findbugs I switched on to see what it would do, but I never got to finish configuring it.
Ari
On 27/12/09 10:21 PM, Andrus Adamchik wrote:
> Hear you. You've been around when we started a switch to Maven, so you
> probably remember me cursing about broken builds roughly on a weekly
> basis. After ~2.5 years of pain now I finally have confidence that I can
> deal with most Maven problems and can't see myself going back to Ant or
> any other of the Java build systems that I know of. Of course we'll keep
> tripping over bugs in new plugin versions, etc., so having our own
> backend repository and fixed plugin versions is likely a needed
> improvement.
>
> Also hopefully the Clover issue will be resolved per Andrey's comment
> and I'd be glad to help diagnosing the broken 1.6 build (which of course
> was caused by my commit).
>
> Andrus
>
>
>
> On Dec 27, 2009, at 1:01 AM, Aristedes Maniatis wrote:
>
>> On 27/12/09 1:39 AM, Andrus Adamchik wrote:
>>>
>>> On Dec 26, 2009, at 3:50 PM, Aristedes Maniatis wrote:
>>>
>>>> Well, we don't have either. Can I suggest for simplicity that we only
>>>> have org.apache.cayenne and nothing else? That's one less thing to
>>>> think about then. I'm happy to go make the change and run a few tests
>>>> if you don't object.
>>>
>>> I suggest to not rush with this. The current layout works ok for us and
>>> this change doesn't buy us anything.
>>
>>
>> Other than the fact that I spent about 6 hours trying to get Clover
>> working and ultimately failed. I'm guessing this is the reason why.
>>
>> http://hudson.zones.apache.org/hudson/job/Cayenne-doc/19/clover-report/
>>
>> And the chasing my tail I've experienced because I've built the
>> project without remembering to 'install' it every single time.
>>
>>
>>> The issue here is not that much the size of it, but rather
>>> user-friendliness and simplicity in handling the artifacts by the end
>>> users. E.g. if I am to deploy Cayenne to my own repo manually for some
>>> reason, I'd have to remember somehow that 1 or 2 parent artifacts also
>>> have to be deployed. This has been a constant annoyance for me with
>>> other frameworks, so I wish that our public modules are only 1 level
>>> deep, and therefore more "portable".
>>
>> If this convoluted and non-standard way of setting up a project is all
>> to work around this one bug in maven (I have no idea why it would need
>> to download the parent pom anyway), then I suggest we let end-users
>> complain to the maven developers. I've wasted many hours on reading
>> the crappy maven docs and trying to figure out what is going on. How
>> to selectively disable modules so that this can work again:
>>
>> http://hudson.zones.apache.org/hudson/job/Cayenne-trunk/
>>
>> or why this isn't working:
>>
>> http://hudson.zones.apache.org/hudson/view/Cayenne/job/Cayenne-doc30/
>>
>>
>> Right now I'm over it. If anyone else can get the project to build the
>> same way twice in a row, please have my blessing to go and change the
>> Hudson configuration.....
>>
>>
>> Ari
>>
>> --
>>
>> -------------------------->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: maven dependency issues
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hear you. You've been around when we started a switch to Maven, so you
probably remember me cursing about broken builds roughly on a weekly
basis. After ~2.5 years of pain now I finally have confidence that I
can deal with most Maven problems and can't see myself going back to
Ant or any other of the Java build systems that I know of. Of course
we'll keep tripping over bugs in new plugin versions, etc., so having
our own backend repository and fixed plugin versions is likely a
needed improvement.
Also hopefully the Clover issue will be resolved per Andrey's comment
and I'd be glad to help diagnosing the broken 1.6 build (which of
course was caused by my commit).
Andrus
On Dec 27, 2009, at 1:01 AM, Aristedes Maniatis wrote:
> On 27/12/09 1:39 AM, Andrus Adamchik wrote:
>>
>> On Dec 26, 2009, at 3:50 PM, Aristedes Maniatis wrote:
>>
>>> Well, we don't have either. Can I suggest for simplicity that we
>>> only
>>> have org.apache.cayenne and nothing else? That's one less thing to
>>> think about then. I'm happy to go make the change and run a few
>>> tests
>>> if you don't object.
>>
>> I suggest to not rush with this. The current layout works ok for us
>> and
>> this change doesn't buy us anything.
>
>
> Other than the fact that I spent about 6 hours trying to get Clover
> working and ultimately failed. I'm guessing this is the reason why.
>
> http://hudson.zones.apache.org/hudson/job/Cayenne-doc/19/clover-report/
>
> And the chasing my tail I've experienced because I've built the
> project without remembering to 'install' it every single time.
>
>
>> The issue here is not that much the size of it, but rather
>> user-friendliness and simplicity in handling the artifacts by the end
>> users. E.g. if I am to deploy Cayenne to my own repo manually for
>> some
>> reason, I'd have to remember somehow that 1 or 2 parent artifacts
>> also
>> have to be deployed. This has been a constant annoyance for me with
>> other frameworks, so I wish that our public modules are only 1 level
>> deep, and therefore more "portable".
>
> If this convoluted and non-standard way of setting up a project is
> all to work around this one bug in maven (I have no idea why it
> would need to download the parent pom anyway), then I suggest we let
> end-users complain to the maven developers. I've wasted many hours
> on reading the crappy maven docs and trying to figure out what is
> going on. How to selectively disable modules so that this can work
> again:
>
> http://hudson.zones.apache.org/hudson/job/Cayenne-trunk/
>
> or why this isn't working:
>
> http://hudson.zones.apache.org/hudson/view/Cayenne/job/Cayenne-doc30/
>
>
> Right now I'm over it. If anyone else can get the project to build
> the same way twice in a row, please have my blessing to go and
> change the Hudson configuration.....
>
>
> Ari
>
> --
>
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
Re: maven dependency issues
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 27/12/09 1:39 AM, Andrus Adamchik wrote:
>
> On Dec 26, 2009, at 3:50 PM, Aristedes Maniatis wrote:
>
>> Well, we don't have either. Can I suggest for simplicity that we only
>> have org.apache.cayenne and nothing else? That's one less thing to
>> think about then. I'm happy to go make the change and run a few tests
>> if you don't object.
>
> I suggest to not rush with this. The current layout works ok for us and
> this change doesn't buy us anything.
Other than the fact that I spent about 6 hours trying to get Clover working and ultimately failed. I'm guessing this is the reason why.
http://hudson.zones.apache.org/hudson/job/Cayenne-doc/19/clover-report/
And the chasing my tail I've experienced because I've built the project without remembering to 'install' it every single time.
> The issue here is not that much the size of it, but rather
> user-friendliness and simplicity in handling the artifacts by the end
> users. E.g. if I am to deploy Cayenne to my own repo manually for some
> reason, I'd have to remember somehow that 1 or 2 parent artifacts also
> have to be deployed. This has been a constant annoyance for me with
> other frameworks, so I wish that our public modules are only 1 level
> deep, and therefore more "portable".
If this convoluted and non-standard way of setting up a project is all to work around this one bug in maven (I have no idea why it would need to download the parent pom anyway), then I suggest we let end-users complain to the maven developers. I've wasted many hours on reading the crappy maven docs and trying to figure out what is going on. How to selectively disable modules so that this can work again:
http://hudson.zones.apache.org/hudson/job/Cayenne-trunk/
or why this isn't working:
http://hudson.zones.apache.org/hudson/view/Cayenne/job/Cayenne-doc30/
Right now I'm over it. If anyone else can get the project to build the same way twice in a row, please have my blessing to go and change the Hudson configuration.....
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: maven dependency issues
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Dec 26, 2009, at 3:50 PM, Aristedes Maniatis wrote:
> Well, we don't have either. Can I suggest for simplicity that we
> only have org.apache.cayenne and nothing else? That's one less thing
> to think about then. I'm happy to go make the change and run a few
> tests if you don't object.
I suggest to not rush with this. The current layout works ok for us
and this change doesn't buy us anything.
I'd rather we first think how to organize the modules in a more
logical fashion, so that it is clear where the code is in development
and how it makes it to the public module. There were complaints from
our own developers in the past that it is not clear what each Maven
module means and how they should work together. Now the things have
gotten worse in the comprehension side. Another practical benefit of
that is the ability to better organize unit tests around the modules.
> But I think the appropriate way to stop certain modules from being
> deployed is this:
Yes, and we are doing that already. I am talking about logical
organization of things here more than the technical side of Maven.
> Maven typically downloads half the internet every time I run it. I
> doubt anyone will notice :-)
The issue here is not that much the size of it, but rather user-
friendliness and simplicity in handling the artifacts by the end
users. E.g. if I am to deploy Cayenne to my own repo manually for some
reason, I'd have to remember somehow that 1 or 2 parent artifacts also
have to be deployed. This has been a constant annoyance for me with
other frameworks, so I wish that our public modules are only 1 level
deep, and therefore more "portable".
Andrus
Re: maven dependency issues
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 27/12/09 12:06 AM, Andrus Adamchik wrote:
>
> Group ID is a namespace. However another one of Maven (optional)
> conventions is to match it with the folder structure. I.e. if our root
> group is "org.apache.cayenne" then everything in the "framework" folder
> should have "org.apache.cayenne.framework" group ID.
Well, we don't have either. Can I suggest for simplicity that we only have org.apache.cayenne and nothing else? That's one less thing to think about then. I'm happy to go make the change and run a few tests if you don't object.
> The only thing that appears bent to me is mixing "public" and
> "unpublished" modules in one place.
But I think the appropriate way to stop certain modules from being deployed is this:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
inserted into each module we want to hide. It should not matter where they are located in the tree.
> The issue with parent is dependency resolving. If a user project
> includes dependency on cayenne-server, this would try to load its parent
> during the build. So if we have two levels of parents, we have more
> garbage for people to download (and us to maintain).
Maven typically downloads half the internet every time I run it. I doubt anyone will notice :-)
> Ideally public
> artifacts should be parent-less (kind of like the new tutorial project).
If it just downloads the parent pom file that should be OK. Pretty small.
> Now cutting release from Hudson could be more tricky. There are a few
> issues that makes it not practical: gpg signing (you don't want a
> committer private key sitting on a shared box), platform specific builds.
I would not expect that the artifacts are signed until AFTER they are built. And shortly we should have Windows and OSX clients for Hudson in the farm. Anyhow, this is a red herring... I'd love to get the other stuff sorted.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: maven dependency issues
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Dec 26, 2009, at 1:43 PM, Aristedes Maniatis wrote:
> I don't understand that. If we only had one group id, there wouldn't
> be any 'odd' group ids. But I don't understand what a maven group id
> actually represents: it looks a bit like a namespace, in which case
> we really should only have one namespace for the whole project.
Group ID is a namespace. However another one of Maven (optional)
conventions is to match it with the folder structure. I.e. if our root
group is "org.apache.cayenne" then everything in the "framework"
folder should have "org.apache.cayenne.framework" group ID.
> There doesn't seem to be anything wrong with the current folder
> structure.
The only thing that appears bent to me is mixing "public" and
"unpublished" modules in one place.
> Only that the modules inside the framework folder should reference a
> parent which is the framework pom itself. And the names of each
> module should match exactly the folder names. If we did just that,
> would anything break?
The issue with parent is dependency resolving. If a user project
includes dependency on cayenne-server, this would try to load its
parent during the build. So if we have two levels of parents, we have
more garbage for people to download (and us to maintain). Ideally
public artifacts should be parent-less (kind of like the new tutorial
project).
>
> That plugin just seems too odd. And one day it would be nice to be
> able to release out of Hudson. That is, to ensure the build
> environment is always reproducible, just pick an artifact Hudson
> builds and name it with a release version. That's what we've been
> doing at my company and it helps a lot.
Just did a quick check using "mvn release:prepare -DdryRun=true" on
the 3.0 branch. It doesn't do any magic. Same thing that we do with
shell : "find . -name pom.xml |xargs perl -i -n -e 's/X-SNAPSHOT/X.X/;
print;'" ... The only difference is snapsot versioning. We always use
3.0-SNAPSHOT and don't change between milestones. maven-release-plugin
increments it. So snapshots go as 3.0B1-SNAPSHOT, 3.0B2-SNAPSHOT,
3.0B3-SNAPSHOT, etc.., which actually makes more sense and we can
adopt this numbering scheme as well.
Now cutting release from Hudson could be more tricky. There are a few
issues that makes it not practical: gpg signing (you don't want a
committer private key sitting on a shared box), platform specific
builds.
Andrus
Re: maven dependency issues
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 26/12/09 9:42 PM, Andrus Adamchik wrote:
>
> The group vs. actual location mismatch is because we have public
> modules, in which we don't want to expose any odd group ids to the end
> users.
I don't understand that. If we only had one group id, there wouldn't be any 'odd' group ids. But I don't understand what a maven group id actually represents: it looks a bit like a namespace, in which case we really should only have one namespace for the whole project.
> We may try to improve things in 3.1. The addition of extra
> "unpublished" modules in 3.1 has made things less comprehensible again,
> so some reorg (invisible to the end users) may be a good thing. Maybe
> separate public aggregated modules in a their own location (hmm... still
> putting them at the root of the checkout to ensure the folder structure
> follows maven guidelines would crowd the root folder ... need to think
> about it).
There doesn't seem to be anything wrong with the current folder structure. Only that the modules inside the framework folder should reference a parent which is the framework pom itself. And the names of each module should match exactly the folder names. If we did just that, would anything break?
> Also I wanted to play a bit with maven-release-plugin that may clean up
> publicly visible structure:
>
> http://maven.apache.org/plugins/maven-release-plugin/index.html
>
> In the past the fact that it alters SVN from Maven gave me an uneasy
> feeling. The plugin behavior still looks a little odd. But since it is
> next to impossible to permanently break things in SVN, I guess I may
> give it a try one day.
That plugin just seems too odd. And one day it would be nice to be able to release out of Hudson. That is, to ensure the build environment is always reproducible, just pick an artifact Hudson builds and name it with a release version. That's what we've been doing at my company and it helps a lot.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: maven dependency issues
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Dec 26, 2009, at 9:47 AM, Andrey Razumovsky wrote:
> 2009/12/26 Aristedes Maniatis <ar...@ish.com.au>
>
>>
>> 1. The top level pom (cayenne-parent) has a module "framework". The
>> framework (cayenne-framework-parent) pom has a parent "cayenne-
>> parent" and
>> has a module "cayenne-tools". The cayenne-tools pom has a parent
>> "cayenne-parent" rather than "cayenne-framework-parent". That is,
>> modules
>> represent the children, and parent should be the reverse of that.
>> But in
>> this case, the parent points to the grandparent.
>>
>
> To me, this looks incorrect. Parent should be cay-framework-parent
>
>
>>
>> 2. Why are there inconsistent groupids? org.apache.cayenne.parents
>> and
>> org.apache.cayenne. Can we just have one groupid for the entire
>> project?
>>
>
> Again, I don't think this is fine..
The group vs. actual location mismatch is because we have public
modules, in which we don't want to expose any odd group ids to the end
users. We may try to improve things in 3.1. The addition of extra
"unpublished" modules in 3.1 has made things less comprehensible
again, so some reorg (invisible to the end users) may be a good thing.
Maybe separate public aggregated modules in a their own location
(hmm... still putting them at the root of the checkout to ensure the
folder structure follows maven guidelines would crowd the root
folder ... need to think about it).
Also I wanted to play a bit with maven-release-plugin that may clean
up publicly visible structure:
http://maven.apache.org/plugins/maven-release-plugin/index.html
In the past the fact that it alters SVN from Maven gave me an uneasy
feeling. The plugin behavior still looks a little odd. But since it is
next to impossible to permanently break things in SVN, I guess I may
give it a try one day.
Andrus
Re: maven dependency issues
Posted by Andrey Razumovsky <ra...@gmail.com>.
2009/12/26 Aristedes Maniatis <ar...@ish.com.au>
>
> 1. The top level pom (cayenne-parent) has a module "framework". The
> framework (cayenne-framework-parent) pom has a parent "cayenne-parent" and
> has a module "cayenne-tools". The cayenne-tools pom has a parent
> "cayenne-parent" rather than "cayenne-framework-parent". That is, modules
> represent the children, and parent should be the reverse of that. But in
> this case, the parent points to the grandparent.
>
To me, this looks incorrect. Parent should be cay-framework-parent
>
> 2. Why are there inconsistent groupids? org.apache.cayenne.parents and
> org.apache.cayenne. Can we just have one groupid for the entire project?
>
Again, I don't think this is fine..
>
> 3. Why is the version in the 3.0 poms still referring to 3.0-SNAPSHOT,
> rather than 3.0-BETA1? And why do we have to change that in 20 files? Can't
> maven inherit from the top pom somehow?
>
Because this is code in change - snapshot. Version is only changed during
release building. Otherwise we risk to have many builds that "are" BETA-1.
We can't have it in just one parent POM because every module is on its own.
E.g. you can run install for only cay-jdk15-unpublished - then it needs to
know its own version and what is the version of its parent.
>
> 4. Will changing the above things be disruptive to the maven universe now
> that artifacts have already been deployed?
>
>
Theorically yes, but actually no, because mostly you need to depend only on
cayenne-server and cayenne-client artifacts in your app and these will not
change. Also already built artifacts will not change, so problems only can
occur when migrating to newer version. And we will change only current trunk
(3.1) structure (?)
Andrey